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Description 

Field Of The Invention 

This invention relates, In general, to distributed s 
computer networlcs and more specifically to rule-based 
protocol processing for distributed networic directory 
and naming services. 

Background Of The Invention 

With the tremendous growth of data processing by 
means of independent, localized data processing devic- 
es, such as personal computers and mini computers, 
data networks have evolved to connect together physi- 
cally-separated devices and to permit digital communi- 
cation arTKXig the various devices connected to the net- 
work. 

There are several types of networks, including kx:al 
area networks (LANs) and wide area networics (WANs). 
A LAN is a limited area network and data devices con- 
nected to a LAN are generally located within the same 
building. The LAN typically consists of a transmission 
medium, such as a coaxial cable or a twisted pair which 
connects together various computers, servers, printers, 
modenns and other digital devices. Each of the devices, 
which are collectivety referred to as 'nodes", is connect- 
ed to the transmission medium at an address which 
uniquely identifies the node and is used to route data 
from one node to another. A node which provides re- 
sources and services Is called a "server" node and a 
node which uses the resources and sen/ices is called a 
■client" node. A WAN generally encompasses a much 
larger area and may involve common carrier connec- 
tions such as telephone lines. 

The document, CUentServer Computing, by Alok 
Sinha, discloses the general concepts of client-server 
computing technotogy. This oven^iew includes discus- 
sion of the basic paradigm. Industry perspective, tech- 
nology, connectivity interfaces, and future possibilities 
including database interfaces and graphical interfaces. 
This document is a reasonably detailed oven^iew of cli- 
ent-server technology. 

The document, Flexible Protocol Stacks, by C. Ts- 
chudin. speculates about the feasibility of flexible stacks 
and discloses a test system to 'experiment with some 
fundamental problems which arise when protocol stacks 
are reconfigured dynamically/ This document noted 
that "nnore research is needed to find stack composition 
techniques," and that more testing and debugging was 
needed. While this document considers the possibility 
of flexible stacks it admits that "the question remains if 
such a protocol environment can be realized," and that 
'[a]t the present state of [their] research not enough is 
known atx>ut the techniques required to handle arbitrary 
protocol stacks and th techniques needed to Imple- 
ment such an environment." Lastly, the document states 
'[b]efore one can hope to have such a general protocol 
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environment... mor understanding about the manage- 
ment of running protocol stacks Is needed." 

LANs and WANs are often connected together in 
various configurations to fonn "enterpris " networks 
which may span different buildings or locations or ex- 
tend across an entire continent. Enterprise networks are 
convenient for several reasons: they altow resource 
sharing - programs, data and equipment are available 
to all nodes connected to the network without regard to 
the physical locatbn of the resource and the user. En- 
terprise networics nr^y also provide relebility by making 
several redundant sources of data available. For exam- 
ple, Important data files can be replicated on several 
storage devices so that, if one of the files is unavailable, 
for example, due to equipment failure, the duplicate files 
are available. 

One of the most Important characteristics of enter- 
prise networks is that they have the capability of bringing 
a large and sophisticated set of services to all of the at- 
tached users for a reasonable cost. However, for the us- 
ers to expk>it the network potential, they must be able 
to identify, locate and access the network resources. 
When a network is small, locating and accessing the 
available services is relatively simple, but networks are 
growing larger and there are many networks that pres- 
ently very large. Thousand node networks are common 
and million node networks are on the horizon. 

An example of a very large network is the INTER- 
NET network, which is used by some of the largest pub- 
lic and private organizations. Much of the power of this 
type of networic goes unused simply because the users 
are either unaware of the facilities available to them or 
they find the methods of accessing the facilities difficult 
or confusing. Consequently, in order to assist users in 
locating and accessing network resources, nnany exist- 
ing networks today utilize networic directory or naming 
services which accept a resource kJentifier or name from 
a user and lcx:ate the network acJdress that corresponds 
to the desired network resource. 

For example, the entered kJentifier or name can be 
"descriptive" and specify a resource by describing 
enough of its attributes to distinguish it from other re- 
sources. Such descriptive names are most useful to hu- 
man users who are searching the network for a resource 
that meets certain specified criteria, but they are also 
require the most computing resources and are often dif- 
ficult to distribute effectively. There presently exist a 
number standards for such descriptive name services. 
For example, the Consultative Committee on Intema- 
tional Telephony and Telegraphy (CCITT) and the Inter- 
national Stanciards Organization (ISO) have devebped 
a standard for a descriptive name service known as X. 
500 

Naming and directory services (these will be re- 
ferred to together as "directory sen/ices' hereafter) are 
presently implemented in a variety of ways. Th sim- 
plest Implementatkjn is to use a single, centralized da- 
tabase contained in a local server nod to hold a list of 
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names and cx>rresponding network addresses. An ex- 
ample of such a localized directory sen/ic is shown in 
Figure 1 . Figure 1 illustrates a computer network ar- 
ranged in a "client-sewer" configuration comprising a 
plurality of cll nt nodes 106, 108, 120. 122 and 128 s 
which may, for exampi ,b workstatbns. personal com- 
puters, minicomputers or other computing devices on 
which run application programs that communk:ate over 
various network links including links 102, 110, 116, 126 
and 1 36 with each other and with server nodes, such as 
nodes 100, 112, 124, 132 and 138. The server nodes 
may contain specialized hardware devices and software 
programs that can provide a service or set of services 
to all or some of the client nodes. The client nodes are 
the users of the various network sen^ices which, in tum, 
are provkied by the sen/er nodes 

Typically, the centralized directory service database 
104 is kx:ated in one of the server nodes, such as node 
100. A client node, such as client node 108, can access 
the directory service by connecting to server node 100, 
entering a resource identifier or name and retrieving the 
network address of the associated sendee. By means 
of conventional database technk^ues. a client node may 
be able to search over the database in order to locate a 
given resource. In addrtbn. many directory services 
support browsing by using partial name descriptions, 
'wiki cards' and placeholders. Such centralized direc- 
tory servk;es with single databases work well in small 
networks where the number of network addresses is 
small. However, in larger networks, it is often not feasi- 
ble to store all the resource Identifiers in one central lo- 
cation. Further, a single database represents a single 
point of failure whbh can disable the entire network. In 
addftk)n, a centralized database often suffers from poor 
performance. For example, while it may be relatively ef- 
ficient for a local client, such as client 108, to connect 
to server 1 00 and access database 1 04. a remote client, 
such as client 1 20, which must link through several send- 
ers, 124 and 112, ak>ng with a 'gateway* link 116, will 
incur a significant amount of network overhead and the 
overall system "cost" of the access will be high. With a 
large number of renrK>te access attempts, directory serv- 
ice provider 100 can quickly become both a processing 
and communication bottleneck for the entire network. 

In order to overcome these problems, additkxial pri- 
or art techniques have been developed which distribute 
the database data over multiple locations. Such a sys- 
tem is shown schematically in Figure 2. Figure 2 depk:ts 
a client-server type of network which is similar to that 
shown in Figure 1. In particular, elements whch corre- 
spond in the two figures have corresponding numeral 
designatbns. For example, client 108 in Figure 1 is sim- 
ilar to client 208 in Figure 2. The difference between the 
two networks is that the directory sendee database has 
been replicated in a number of the server nodes. For 
example, sender nod 200 contains a directory service 
database 204 as do server nodes 21 2 (database 21 4), 
server nod 232 (database 230) and serv r node 224 



(datat>ase218).Ther ar a n umber of prk>r art methods 
for r plk:ating th data in each of th databases. Som 
systems r plk:ate each resource identifier individually in 
each database, other systems r plicate the entir data- 
base. Still other systems replk:ate individual nod s or 
limit replication by partitioning the database in some 
manner. 

The distributed system shown in Figure 2 avoids the 
problems associated with the centralized database. 
Since the data is replicated, there is no single point of 
failure and, since the data is usually available on a near- 
by sender node, there are no "remote" client nodes and 
network overhead is greatly reduced. 

However, the distributed system has its own prob- 
lems. For example, some method must be used to in- 
sure data consistency if multiple sources can update the 
databases. Some systems force data consistency by 
keeping all copies of the data tightly synchronized in a 
manner similar to a conventional database system. Oth- 
er system insure data integrity by means of conventional 
concurrency arbitration schemes. 

Such distributed naming and directory services are 
effective on homogeneous networics in which the same 
access methods and protocols apply over the entire net- 
work. In this case, a consistent set of names and rules 
can be devebped to permit locatk)n and access of var- 
bus resources with relative ease. However, many large 
networks are heterogeneous - not only do the networks 
comprise many types of different computers, including 
work statrans, personal computers, mini-computers, su- 
per-computers and main frames, but the network itself 
is often composed of many independent smaller net- 
works whbh are connected together by interfaces called 
"gateways". These smaller networks may have their 
own access methods and protocols. Further, the heter- 
ogeneous construction and organization of these large 
networks does not lend itself to central control arKi man- 
agement which could dictate comnrK>n methods and pro- 
tocols. 

In many large networks which are comprised of a 
set of smaller networks which are connected together, 
each of the underlying separate networks may have its 
own different directory service utilizing a specific proto- 
col. I n this type of network a user may have to be familiar 
with each network directory servce protocol and may 
have to shift from protocol to protocol as searches are 
performed from networtc to network. Consequently, in 
such a heterogeneous network, one of the main difficul- 
ties in accessing networic resources arises from a lack 
of a consistent gbbally-accessible directory of network 
resources whbh can operate over heterogeneous net- 
works without involving the user in the details and the 
protocol involved in accessing each of these separate 
networks. 

Today's networking servbes have various protocol 
systems. In the prior art, applrcations must contain de- 
tailed informatbn pertaining to protocol architectures for 
networking. This requirement mandated applicatk>n ties 
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to particular protocols. This prevented dynarnic config- 
uration ot networks because applications could not sup- 
port protocol changes without a source code change. 

Accordingly, it is an object of th pr sent inv ntion 
to allow applicatbns to specify a type and quality of serv- 
ice. 

Summary Of The Invention 

The foregoing problems are solved and the forego- 
ing objects are achieved In one illustrative embodiment 
of the invention in which a rule based protocol selection 
mechanism selects the appropriate protocol configura- 
tion based on the type and quality of service. For each 
protocol family, a set of rules is defined to translate the 
type and quality of service into a particular set of com- 
mon protocols. 

Brief Description Of The Drawings 

The above and further advantages of the invention 
may be better understood by referring to the following 
description in conjunction with the accompanying draw- 
ings, in which: 

Figure 1 is a block schemata diagram of a prior art 
client server network which incorporates a kx^al direc- 
tory service. 

Figure 2 is a block schematk; diagram of a prior art 
client sender network which incorporates a distributed 
directory sender. 

Figure 3 is a bkxk schematic diagram of a computer 
system, for example, a personal computer system in 
which the rule based protocol selection mechanism op- 
erates. 

Figure 4 is a block schematk: diagram of a client 
server network which irKX>rporates the rule based pro- 
tocol selection mechanism. 

Figure 5 is a detailed bkx:k schemata diagram of a 
prior art protocol stack used to transmit data between 
two nodes structure in accordance with the Intematkxial 
Standards Organization seven layer model. 

Figure 6 is a bkx:k schematk: diagram of the nrtajor 
components of the communk:ations directory sen^ice. 

Figure 7 is a schematic diagram of an illustrative 
directory tree set up which alk>ws browsing over various 
directory sen/ices and other network services. 

Figure 8 is a block schematic diagram of the nr«in 
components of a server node illustrating how a sen^ice 
program interacts with the communications directory 
service. 

Figure 9 is a simplified flowchart of the steps in- 
volved in making a new service available on the net- 
work. 

Figure 1 0 is an expanded flowchart of the steps car- 
ried out by the service program in order to activate a 
sen/ice object. 

Figure 1 1 is a block schematic diagram of the main 
components of a client node illustrating how an applica- 
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tion program interacts with the communications directo- 
ry s rvic to access a service. 

Figur 12 is a simplified flowchart of the steps in- 
volved in acc ssingas n^ic availabi on the network. 
s Figur 1 3 is an expanded flowchart of the steps car- 
ried out by the sen/ice program in order to activate a 
sennce object. 

Detailed Description Of Illustrative Embodiments 

10 

The invention is preferably practiced in the context 
of an operating system reskjent on a personal computer 
such as the I Bl^^ PS/2^ or Apple™ Macintosh™ com- 
puter A representative hardware environment is depict- 

15 ed in Figure 3, which illustrates a typk^l hardware con- 
figuration of a computer 300 in accordance with the sub- 
ject invention. The computer 300 is controlled by a cen- 
tral processing unit 302, whk:h nr^y be a conventk>nal 
microprocessor; a number of other units, all intercon- 

20 nected via a system bus 308, are provkjed to accom- 
plish specifk: tasks. Although a partk:ular computer may 
only have some of the units illustrated in Figure 3 or may 
have additional components not shown, most comput- 
ers will include at least the units shown. 

25 Specifically, computer 300 shown in Figure 3 in- 
cludes a random access memory (RAM) 306 for tempo- 
rary storage of informaton, a read only memory (ROM) 
304 for permanent storage of the computer's configura- 
tion and basic operating commands and an input/output 

30 (I/O) adapter 310 for connecting peripheral devices 
such as a disk unit 313 and printer 314 to the bus 308. 
via cables 315 and 312, respectively, A user interface 
adapter 316 is also provided for connecting input devic- 
es, such as a keyt>oard 320, and other known interface 

35 devk^es including mk:e, speakers and microphones to 
the bus 308. Visual output is provkied by a display 
adapter 318 which connects the bus 308 to a display 
devk;e 322 such as a video monitor. The workstation has 
resident thereon and is controlled and coordinated by 

40 operating system software such as the Apple System/ 
7™ operating system. 

In a preferred embodiment, the inventbn is imple- 
mented in the C++ programming language using object- 
oriented programming techniques. C++ is a compiled 

45 language, that is, programs are written in a human-read- 
able script and this script is then provided to another 
program called a compiler which generates a machine- 
readable numeric code that can be k>aded into, and di- 
rectly executed by, a computer. As described below, the 

50 C++ language has certain characteristcs which altow a 
software developer to easily use programs written by 
others while still provkiing a great deal of control over 
the reuse of programs to prevent their destruction or im- 
proper use. The C++ language is well-known and many 

55 articles and texts are available which describe the tan- 
guag in detail. In additkxi. C++ compilers are commer- 
cially available from several vendors including Borland 
Intematbnal, Inc. and Mrcrosoft Corporatbn. Accord- 
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ingty. for reasons of clarity, the details of the C-m- lan- 
guage and th operation of th C++ cx)mpiler will not be 
discussed further in detail herein. 

As will be understood by thos skilled in th art, Ob- 
ject-Oriented Programming (OOP) techniques Involve 
the definition, creation, use and d struction of 'objects". 
These objects are software entities comprising data el- 
ements and routines, or functions, which manipulate the 
data elements. The data and related functions are treat- 
ed by the software as an entity and can be created, used 
and deleted as if they were a single item. Together, the 
data and functions enable objects to model virtually any 
real-world entity in terms of its characteristics, which can 
be represented by the data elements, and its behavior, 
which can be represented by its data manipulation func- 
tions. In this way, objects can model concrete things like 
people and computers, and they can also model ab- 
stract concepts like numbers or geometrical designs. 

Objects are defined by creating 'classes* which are 
not objects themselves, but which act as templates that 
instruct the compiler how to construct the actual object. 
A class may, for example, specify the number and type 
of data variables and the steps involved in the functions 
whk;h manipulate the data. An object is actually created 
in the program by means of a special function called a 
constructor whfch uses the corresponding class defini- 
tion and additonal information, such as arguments pro- 
vided during object creatkxi, to construct the object. 
Likewise objects are destroyed by a special function 
called a destructor Objects may be used by using their 
data and invoking their functions. 

The principle benefits of object-oriented program- 
ming technques arise out of three basic principles; en- 
capsulatk^, polymorphism and inheritance. More spe- 
cifically, objects can be designed to hide, or encapsu- 
late, all, or a portion of, the internal data structure and 
the internal functions. More partcularly, during program 
design, a program developer can define objects in which 
all or some of the data variables and all or some of the 
related furK:tions are considered 'private' or for use only 
by the object itself. Other data or f unctkxis can be de- 
clared 'publk:' or available for use by other programs. 
Access to the private variables by other programs can 
be controlled by defining public f unctkxis for an object 
which access the object's private data. The public func- 
tions form a controlled and consistent interface between 
the private data and the 'outside' worki. Any attempt to 
write program code which directly accesses the private 
variables causes the compiler to generate an error dur- 
ing program compilation whk:h error stops the compila- 
tion process and prevents the program from being mn. 

PolynKjrphism is a cor»cept whteh altows objects 
and functk>ns which have the same overall format, but 
whch work with different data, to function differently in 
order to produce consistent results. For example, an ad- 
ditk)n functkxi may be defined as variabi A plus varia- 
bl B (A+B) and this same format can be used whether 
th A and B are numbers, characters or dollars and 



cents. However, the actual program code which per- 
forms th additk>n may differ widely depending on th 
type of variables that comprise A and B. Polynr>orphism 
allows thre separat functton definitions to be written, 

5 one for each type of variabi (numbers, charact rsand 
dollars). After the functions have been defined, a pro- 
gram can later refer to the addition function by its com- 
mon format (A+B) and, during compilation, the C++ 
compiler will determine which of the three functions is 

10 actually being used by examining the variable types. 
The compiler will then substitute the proper functk>n 
code. Polymorphism altows similar functtons which pro- 
duce analogous results to be 'grouped' in the program 
source code to produce a more logk:al and clear pro- 

^5 gram flow. 

The third principle which underiies object-oriented 
programming is inheritance, which altows program de- 
ve topers to easily reuse pre-existing programs and to 
avokJ creating software from scratch. The principle of 

20 inheritance allows a software devetoper to declare 
classes (and the objects which are later created from 
them) as related. Specifically, classes may be designat- 
ed as subclasses of other base classes. A subclass 'in- 
herits' and has access to all of the publb functions of its 

25 base classes just as if these functton appeared in the 
subclass. Alternatively, a subclass can overrtoe some 
or all of its inherited functions or may modify some or all 
of its inherited f unctk>ns merely by defining a new func- 
tion with the same form (overriding or modificatton does 

30 not alter the functton in the base class, but merely mod- 
ifies the use of the function in the subclass). The creation 
of a new subclass which has some of the functtonality 
(with selective modification) of another class altows soft- 
ware developers to easily customize existing code to 

35 meet their parttoular needs. 

Although object-oriented programming offers sign if - 
k:ant improvements over other programming concepts, 
program devek>pment still requires significant outlays of 
time and effort, especially if no pre-existing software 

40 programs are available for modification. Consequently, 
a prior art approach has been to provkJe a program de- 
vetoper with a set of pre-defined, interconnected class- 
es whtoh create a set of objects and additional miscel- 
laneous routines that are all directed to performing com- 

45 monly-encountered tasks in a parttoular environment. 
Such pre-defined classes and libraries are typically 
called 'appltoation frameworks' and essentially provide 
a pre-fabricated structure for a working applicatton. 
For example, an application framework for a user 

50 interface might provide a set of pre-defined graphic in- 
terface objects which create windows, scroll bars, men- 
us, etc. and provkJe the support and "default' behavior 
for these graphto interface objects. Since applk^tton 
frameworks are based on object-oriented techniques, 

55 the pre-defined classes can be used as base classes 
and the built-in default behavtor can be inherited by d - 
ve toper-defined subclasses and either modified or over- 
ridden to altow developers to extend the f ram work and 
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creat customized solutions in a particular ar a of x- 
p rtis . This object-cri nted approach provides a major 
advantage over traditional programming since th pro- 
gramm r is not changing the original program, but rather 
extending th capabilities of the original program. In ad- s 
ditbn, developers are not blindly working through layers 
of code because the framework provides architectural 
guidance and modeling and, at the same time, frees the 
developers to supply specific actions unique to the prob- 
lem domain. 

There are many kinds of application frameworks 
available, depending on the level of the system involved 
and the kind of problem to be solved. Ttie types of frame- 
works range from high-level application frameworks that 
assist in devek>ping a user interface, to lower-level 
frameworks that provide bask: system software services 
such as communicatkxis, printing, file systems support, 
graphics, etc. Commercial examples of application 
frameworks include MacApp (Apple). Bedrock (Syman- 
tec), OWL (Borland), NeXT Step App Kit (NeXT), and ^ 
Smalltalk-80 MVC (ParcPIace). 

While the applicatk>n framework approach utilizes 
all the principles of encapsulation. polyrDorphism, and 
inheritance in the object layer, and is a substantial im- 
provement over other programming techniques, there 
are difficulties which arise. These difficulties are caused 
by the fact that it is easy for developers to reuse their 
own objects, but it is difficult for the developers to use 
objects generated by other programs. Further, applk:a- 
tion frameworks generally consist of one or more object 30 
'layers" on top of a monolithc operating system and 
even with the flexibility of the object layer, it is still often 
necessary to directly interact with the underlying oper- 
ating system by means of awkward procedural calls. 

I n the same way that an applk:ation framework pro- 3S 
vides the devek>per with prefab functbnality for an ap- 
plication program, a system framework, such as that in- 
cluded in a preferred embodiment, can provkle a prefab 
f unctk)nality for system level sen^k:es which devek>pers 
can modify or override to create customized solutkxis, 40 
thereby avokJing the awkward procedural calls neces- 
sary with the prior art applicatk>n frameworks programs. 
For example, consider a printing framework which could 
provide the foundation for automated paginatk>n, pre- 
print processing and page composition of printable in- 4S 
formatkxi generated by an applbatkxi program. An ap- 
plication software developer who needed these capabil- 
ities woukJ ordinarily have to write specific routines to 
provide them. To do this with a framework, the developer 
only needs to supply the characteristics and behavior of so 
the finished output, while the framework provkJes the ac- 
tual routines which perform the tasks. 

A preferred embodiment takes the concept of 
frameworks and applies it throughout the entire system, 
including the applk:ation and the operating system. For ^ 
the commercial or corporate deve toper, systems inte- 
grator, or OEM, this means all of the advantages that 
have been illustrated for a framework such as MacApp 



can be leveraged not only at the apptk:atkxi level for 
such things as text and us r interfaces, but also at th 
system level, for sendees such as prinfing, graphics, 
multi-media, file syst ms, I/O. t sting, tc. 

Figure 4 shows a sch matic overview of the illus- 
trative client- server network illustrated in Figures 1 and 
2 which has now been provided with the communica- 
tions directory sen^ice. A comparison of Figures 2 and 
4 indicates that, although the general network configu- 
ration is the same for both networks, when the commu- 
nications directory service is used as shown in Figure 
4, all of the nodes now include a communicattons direc- 
tory service (CDS) module. In particular, server nodes 
400, 412, 424. 432 and 438 now include the communi- 
cafions directory servk:e modules 405, 413, 425. 430 
and 439, respectively. In addition, any or all server 
nodes may also include a conventtonal directory sen/ice 
404, 414, 418 and 430, respectively. These convention- 
al directory services will be referred to as physk:al direc- 
tory services hereinafter to distinguish then from the 
communications directory sen^ice. 

In addition to the sender nodes, each of the client 
nodes 406. 408, 420. 422 and 428 (CDS 407.-409, 421 . 
423 and 429, respectively) also includes a communica- 
tions directory service. As will hereinafter be explained 
in detail, in enterprise networks such as that shown in 
Figure 4, information to be sent from one node to anoth- 
er is generally divkied into discrete messages or "pack- 
ets" and the packets are transmitted between nodes in 
accordance with a predefined "protocol". In this context 
a "protocol' consists of a set of rules or procedures de- 
fining how the separate nodes are supposed to interact 
with each other. 

In order to reduce design complexity, most networks 
are organized as a series of "layers" or "levels" so that 
informatbn passing from one node to another is trans- 
mitted from layer to layer. Wrthin each layer, predeter- 
mined servk:es or operattons are performed and the lay- 
ers communk:ate with each other by means of prede- 
fined protocols. The purpose for the layered design is to 
allow a given layer to offer selected services to other 
layers by means of a standardized interface while 
shielding those layers from the details of actual imple- 
mentatton within the layer. As will hereinafter explained 
in detail, both the client and server nodes cooperate with 
the communications directory sen^ice modules in order 
to structure the network layers whbh, in turn, control the 
type and parameters of the connections between client 
and servers in accordance with the type of service being 
offered. 

In an attempt to standardize network architectures 
(the overall name for the sets of layers and protocols 
used within a network), a generalized model has been 
proposed by the Intemattonal Standards Organ izatton 
(ISO) as a first step towards international standardiza- 
tion of th vartous protocols now in use. Th model is 
called th open systems interconnect ton (OSI) r fer- 
ence model because it deals with th int rconnection of 
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systems that are "open' for communication with oth r 
systems. Th proposed OSI model has seven layers 
which are termed (in the order which they interface with 
each other) the "physicar, "data link', •network*, trans- 
porf, 'sessbn*. "prss ntation* and 'applicatbn' lay rs. 
The purpose of th OSI model is to attempt to standard- 
ize the processes conducted within each layer 

In accordance with the OSI nrKxjel, the processes 
carried out in the physical layer are concerned with the 
transmisskxi of raw data bits over a communication 
channel. The processes carried out in the data link layer 
manipulate the raw data bit stream and transform it into 
a data stream that appears free of transmisskxi errors. 
The latter task is accomplished by breaking the trans- 
mitted data into data frames and transmitting the frames 
sequentially accompanied with error correcting mecha- 
nisms for detecting or correcting errors. 

The network layer processes determine how data 
packets are routed from the data source to the data des- 
tination by selecting one of many alternative paths 
through the network. The function of the transport layer 
processes is to accept a data stream from a session lay- 
er, split it up into smaller units (if necessary), pass these 
smaller units to the network layer, and to provide appro- 
priate mechanisms to ensure that the units all arrive cor- 
rectly at the destination, with no sequencing errors, du- 
plk:ates or missing data. 

The sessbn layer processes albw users on differ- 
ent machines to establish "sessbns" or 'dialogues' be- 
tween themselves. Asesskxi allows ordinary data trans- 
port between the communicating nodes, but also pro- 
vides enhanced servk;es in some applicatbns, such as 
dialogue control, token management and synchroniza- 
tion. The presentation layer performs certain common 
f unctk>ns that are requested sufficiently often to warrant 
finding a general solution for them, for example, encod- 
ing data into a standard fornr^t, performing encryption 
and decryptk>n and other functions. Finally, the applica- 
tion protocol layer contains a variety of protocols that 
are comnrKxily needed, such as database access, file 
transfer, etc. 

For example. Figure 5 is a diagram of a prior art 
protocol stack used to connect two nodes in accordance 
with the OSI standard seven-layer architecture. In ac- 
cordance with the OSI standard, each protocol stack for 
a node consists of seven layers. For example, stack 528 
for Client node 408 comprises an application layer 500, 
a presentation layer 502, a sesskxi layer 504, a trans- 
port layer 506, a network layer 508, a data link layer 51 0 
and a physk:al layer 512. The operation and the purpose 
of each of these layers has been previously discussed. 
Similarfy, stack 532 for Sen/er node 432 consists of lay- 
ers 514-526. Although the actual data communbation 
occurs between the two physical layers 512 and 526 
over a data link 530, when the stack is arranged as 
shown in Figur 5, each layer can be thought of as com- 
mun Keating with its "peer" which is a layer at th same 
level as a given layer. For example, the applicatkjn lay- 



rs 500 and 514 can be thought of as communicating 
directly v n though informatbn passes through all of 
the layers 502-512, across data link 530 and back 
through th layers 516-526. Similarly presentatkxi lay- 

s ers 502 and 51 6 can communicate p er-to-peer. 

The protocol stacks such as those shown in Figure 
5 are typrcally implemented using a plurality of data buff- 
ers. Each data buffer constitutes a protocol layer In 
which processing is done. After processing is complete 

10 in a layer the data may be transferred to another buffer 
for further processing in accordance with another layer. 

In accordance with one aspect of the inventk>n, the 
protocol stacks whrch control peer-to-peer communica- 
tions in the network are configured by stack definitions 

IS stored in the communicatk>ns directory service, these 
stack definitbns are associated with each servk^e type 
available on the network so that the protocol stacks can 
be dynamk:ally configured in response to servce re- 
quests from the applbatk3n programs. 

20 A more detailed diagram of a communicatkxis di- 
rectory sen/ice module is shown in detail in Figure 6; the 
nrK)dule includes three nr\ajor components: a hierarchical 
directory tree 602 whk:h allows each of the physical di- 
rectory services and other servk:es provkted by the net- 

25 work to be located by means of a conventional tree 
searching techniques; a set of stack definitbn objects 
604 which are used to program the dynamically recon- 
figurable stacks that alk>w a client to request data from 
a remote sender over a prespecified communcatkyi link 

30 and a set of "service objects" 606. Each sen^ice object 
is associated with one service available on the network 
and contains the network address or exchange address 
at whk:h the sen/ice is available and a reference 608 to 
one or more of the stack definitk>n objects 604. As will 

3S hereinafter be explained in detail, a reference to one of 
these sen^ice objects is obtained by an application pro- 
gram desiring to access the corresponding sen^ice. The 
informaton in the object identified by this reference is 
then sent to the reconfigurable stack in order to set up 

^ the communication path. 

The stack definitkxis 604 each consist of a set of 
layer definitions that specify the processing carried out 
in each layer and the interactk)ns between the layers. 
The stack definitions are defined at the time that the 

4S communbations links are installed on the network sys- 
tem. In particular a stack definition is provided for each 
different type of communicatkxi link on the system. 

The communbations directory service 600 has a 
number of other features whbh make its operation par- 

50 ticularly convenient for users on the network. In partic- 
ular, the directory service stores information regarding 
the available servbes and directory servbes in the di- 
rectory tree as a series of objects. In additk>n, the stored 
libraries in the communications directory servbe contain 

55 objects and, thus, both applbatk>n programs and serv- 
be programs can communicate directly with the com- 
munications directory service by means of objects. 
Since the communicatkxis directory servbe is present 
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oh each of the nodes, a client need not connect with any 
directory senile s rv rb fore using the directory serv- 
ice, instead the objects themselves provide the inter- 
fac . Further, th us of predefined objects, such as th 
s rvice objects 606, provides a sinnple method to allow 
an application program to open communications with a 
desired service. The service objects can be sent directly 
to the networking service in order to open a communi- 
cations path without requiring the application program 
to concern itself with the details of the actual path con- 
struction. In addition, because any existing physical di- 
rectory services are encapsulated in the node objects 
of the directory tree 602, the physical directory sen^ices 
are completely hidden from the client application allow- 
ing the client application to interact with the communi- 
cations directory service with a consistent protocol and 
feature set. 

A more detailed diagram of the directory tree 602 
found in the communications directory service is shown 
in Figure 7. As will hereinafter be explained, the direc- 
tory tree can be traversed by means of simple search 
commands and full browsing capabilities are provided 
by using wild cards and placeholders. The directory tree 
is designed so that objects are returned as the result of 
searches with the type of object which Is returned being 
determined by the implementation of the portion of the 
directory which returns the object. Examples objects 
which can be returned from a directory tree search are 
references to the service objects 606 shown in Figure 6 
which contain information used to connect to rernoXe 
service; principle objects which contain security and au- 
thenticatbn information about users; 'business cards" 
which contain collections of infornr^tion about users and 
other classes which nnay be added to the directory tree 
by program developers. The directory tree is organized 
as a single hierarchical tree such as that shown In Figure 
7. It should be noted that the tree configuration shown 
in Figure 7 is for an illustrative purposes only and an 
actual tree configuration can differ significantly from the 
Illustrated configuration without departing from the 
scope and principles of the present invention. Each of 
the nodes In the tree is formed by a 'namespace" object. 
A namespace object can refer to other namespace ob- 
jects or can refer directly to services or other physical 
directory services. The ultimate root of the directory tree 
is the root namespace object 700; the root namespace 
object 700 and the other namespace objects which form 
the nodes of the tree are inserted into a conventional 
tree structure which can be traversed to find the node 
members. 

Each node object, such as root namespace object 
700, includes methods which facilitate directory search- 
es. In particular, these methods may include a search 
method which returns an iterator over all entries in the 
directory, a method which returns entries to which the 
namespace refers and a m thod which returns entries 
that match a given property expression. Additional 
methods may be provided to obtain the root namespace 



from lower level directory node. 

In the tree directory shown in Figur 7, the ultimat 
nodes or 'leaf nodes ar the physical directory services 
and the other available network servk:es. As these leaf 

5 nodes ar also namespace objects, they may include 
methods which return th associated directory protocol 
and methods which can interact with the physical direc- 
tory to search or browse the directory. Since each ot the 
leaf nodes contains methods which are written specift- 

10 cally for the associated service, the methods deal with 
the protocol Issues involved with the associated service 
allowing the user to interface with the communicatk)ns 
directory service In a consistent manner no matter what 
directory service is involved. 

15 For example. In Figure 7, three nodes 704, 706 and 
708 are shown which interact with three separate phys- 
ical directory services. A fourth node, 710, is also pro- 
vided, whk:h node is called a 'native' namespace node. 
This latter node contains a reference to each of the serv- 

^ ices that are provided by the network. As will hereinafter 
be explained, in order to make each service available to 
the users. It Is 'registered' In the nat'rve namespace 710. 
'Registration' In the namespace means to insert a ref- 
erence to the service into the directory where rt can 

25 found by someone traversing the directory. Essentially, 
registration consists ot streaming the associated service 
object Into the native namespace where it can be dis- 
covered by queries. 

In addrt»n, to registering a servk;e, it is also possi- 

30 ble to 'publish' a service In the directory or In the phys- 
ical directory services resident in the leaf nodes. Publi- 
cation differs from registration in that publication In- 
volves inserting a limited set of information about the 
sendee into a directory node. This limited set of informa- 

35 tlon nnay, for example, consist of the sewice name, type 
of sen^ice and a connection address. In a preferred fomi 
of the invention, the native namespace handles publi- 
cations - when a service entity is registered with the na- 
tive namespace, the native name space determines in 

^ which other namespaces the entity shou b be published 
and directs the publication accordingly. 

In order to provide full branching capabilities, inter- 
mediate namespaces, such as name space 702 may be 
inserted between the root namespace 700 and the leaf 

45 nodes 704-710. The intermediate namespace refers to 
other namespaces. As prevkxjsly mentioned, the inven- 
tive communications directory sennce Interacts with 
both service programs and appllcatk>n programs to 
transparently set up the necessary communicatbn links 

50 between the client and server. This interactkxi involves 
the creation of service objects in the communications 
directory servk:e by the service providers and the con- 
figuration of the protocol stacks In the server nodes. A 
client desiring to access a sen^ice retrieves the associ- 

55 ated senf ice object and uses it to configure the protocol 
stacks In the client nod to set up the communication 
link. Figures 8-10 describe the operations performed by 
a sen^ice program op rating in a server nod in order to 
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make a new service available on the network for use by 
application programs running in the cli nt nodes. Figur 
8 is a schematic block diagram of the portions of the 
s rver node programs that ar involved in th cr ation 
and activatbn of a new service. Figur 9 is an illustrative 
flow chart which describes the interaction betw en the 
sewice program, the communications directory service 
and the node networking sen^ices in order to establish 
the new sen/ice and to configure the networking service 
to operate over an appropriate communication link. Fig- 
ure 1 0 is a more detailed block diagram illustrating the 
activation of the new service by activating the associat- 
ed service object. More particularly, Figure 8 illustrates 
the basic configuratbn of a server node in providing a 
sennce to a remote client. The server node is arranged 
with a comrrK>n area, or system address space, 800 
whk:h address space wouki include operating system 
programs and various shared libraries that are used by 
the service applications running on the system. In par- 
ticular, the system address space 800 Includes the com- 
munications directory sendee 804 and the networking 
sen^lce programs and libraries 816. Also in the sender 
node is the servk:e program which runs in its own ad- 
dress space 810. As will be hereinafter explained, the 
service program 806 interacts with the communications 
directory service 804 to create a service object which 
then resides in the communicatkxis directory service 
804. This servk:e object is distributed to all of the other 
nodes in this system and, thus, is available on a kx:al 
basis to all of the clients on the network. Because the 
service object includes the appropriate stack definitbns 
for configuring the networking service 816, the applrca- 
tion program together with the communications directo- 
ry service can set up the communicatkyis path using the 
previously stored definitions without involving a client 
application program in the constructbn details. 

Referring to Figure 9, the creatkxi of a new service 
begins In step 900 and proceeds to step 902. In step 
902, the developer of the service program enables the 
creation of a new sen^ice object containing configuratbn 
parameters which are appropriate to the new service. 
This may be done by subclassing the service object 
classes located in the directory senfbe. In particular, in 
order to create a new servk^e object class, the service 
program devebper specifies a unque name for the 
service, the type of service and, optbnatty, varbus com- 
munications link types which can be used to access the 
sen^ice. In accordance with normal objectoriented pro- 
gramming language operatkxi, this subclassing infor- 
mation is Included In the service program code during 
compilatkxi. Therefore, when the service program 806 
Is installed in the servbe program address space 810 in 
the appropriate server node, the constructor of the serv- 
ice object subclass can be called to construct a senrice 
object in the communk:atkxYS diredory service 804 as 
illustrated in step 904 (Figure 9). During the process of 
calling the constructor, the type and quality of servce 
information is passed to the communcatons directory 



service as schematically indicated by arrow 802 

As prevk>usly mentk)ned, the communications di- 
rectory service 804 Includes a set of stack definitions in 
shared libraries. These stacks definitk>ns are created 

5 whenth communicatkxis links are defined and are as- 
sociated with a partbular transport mechanism. The 
stack definitions each consist of a set of layer definitbns. 
The layer definitions control the processing of the data 
in each layer and the Interactbns between layers. Each 

10 stack definition completely defines the stack from the 
transport layer through the physical layer (these layers 
are described in detail above). 

In the process of creating a new servbe object, the 
communk^ations directory service 804 uses the type and 

15 quality of servk:e information provided by the service 
program to construct a sessbn layer and include appro- 
priate references to the stored communk:ations stack 
definitions as set forth in step 906. If more than one com- 
municatkxi link can be used to access the new sen^ice, 

20 appropriate stack definitk>ns are referenced in the new 
service object and the sessk3n layer is constructed in 
order to select one of the communk:atk>n links based on 
varbus criteria, such as the quality of servbe desired 
and the availability of the communication link. 

25 Thus, the newly-created servbe object contains a 
sessbn layer and the appropriate stack definitions 
which define the stack from the transport layer to the 
physk:al layer. The servbe object is stored In the com- 
municatkxis directory servbe. However, at this time, no 

30 sendee address or exchange address is provided in the 
sendee object because the sen^ice object, although cre- 
ated, is not active. Thus, a servbe object can be created 
any point when the service program is installed in the 
server node, but the servbe program however does not 

35 become activated until further steps are taken as de- 
scribed bebw. 

More particularty, in order to activate the new serv- 
be, the service program instructs the communbatbns 
directory servbe 804 to send the stored servbe object 

40 to the dynambally reconfigurable protocol stack (DRPS) 
822 in networking sen^ice 816 as descrit>ed in step 908. 
The manner In whbh the service object is transferred to 
the DRPS is illustrated in Figure 8, More partbularly, the 
sendee program 806 first creates a service program in- 

45 terface 828 in its own address space 81 0. The commu- 
nbation between the sen/be program and the sen^be 
program interface is scherrtatically Indicated by arrow 
808. The service program Interface 828. in turn, creates 
a configuration data stream 814 whbh can stream data 

50 to a server interface 818 whbh is permanently available 
and bcated In the networking servbe 816. 

The servbe program 806 then retrieves the sen^be 
object including the network configuration data. The 
configuration data passes from the communications di- 
ss rectory sen^ice to the service program interface 828 as 
indicated by arrow 812. The configuration data is then 
streamed to the system address space 800 as indicated 
by arrow 81 4. 
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Next, as illustrated in step 910, the service program 
activates the servic object which, in turn, causes the 
service exchange address to be returned to the commu- 
nications directory s rvic 804. Amor d tailed descrip- 
tion of the activation sequence is illustrated in th flow s 
chart shown in Figure 10. More particularly, the activa- 
tion sequence starts in step 1000 and proceeds to step 
1002. In step 1002, the communications directory serv- 
ice 804 makes the service available by publishing the 
service on any underlying physical directory sen/ices if 
this is appropriate. This publication consists of register- 
ing the name of the service and, in some cases, the sen^- 
ice address in the underlying directory services. 

TTie routine next proceeds to step 1 004 in which the 
service is registered with the communications directory 
service. As previously mentioned, such registration in- 
volves streaming the service object into the native 
namespace node of the communications directory serv- 
ice. At this point, a reference to the sen^ice is added to 
the CDS directory tree so that the service can be located 
by user traversing the tree. 

Next, in step 1006, the stack definition references 
whk:h have been passed to the server interface 818 in 
networking service 816 by the service program 806 are 
used to set up the stack definitk)ns that will be used to 
reconfigure the DRPS 822. In step 1008, the created 
stack definitkxis are passed to the DRPS (this operation 
is shown schematically by arrow 820). At this time the 
information in the service object is also used to set up 
the sessk>n layer 823. 

In step 1010, the exchange address, or the network 
address, of the sessk)n layer 823 in the DRPS 822 is 
returned to the communicatbns directory servk:e 804. 
In particular, the networking sen^ice 81 6 obtains the ses- 
sion layer address from the DRPS 822 when the session 
layer is set up. This address is retumed, via the service 
interface 818, configuratbn data stream 814, to the 
service program interface 828. Finally, the exchange ad- 
dress is returned, via the data stream 812, to the com- 
munk:ations directory service 804. The exchange ad- 
dress, as previously mentioned, is stored in the associ- 
ated sen^ice object located in the communicatkx^s dh 
rectory sen^k;e 804 so that it can later be retrieved by a 
client program. At this point, activatkxi is complete and 
the activatbn routine shown in Figure 10 ends in step 
1012. In step 912, the exchange address is retumed to 
the communk:atbns directory service and the sen^ice 
activation routine ends in step 914. 

A separate data stream is also set up by the service 
program at this time so that, at a subsequent time, when 
a client node requests service from the server node, the 
incoming service requests can be received. In particular, 
service request data arriving over the physical commu- 
nicatbn link 824 is passed through the configured DRPS 
822 via a separate request data stream 826 whbh links 
the session layer 823 to the service program interf ac 
828. The servk:e program interface 828, in turn, for- 
wards the request, via data stream 808. to the senile 



program 806. Reply information is retumed by sen^be 
program 806, via data stream 808, serv'ce program in- 
terfac 828, request data stream 826, DRPS 822, and 
physical communicatbn link 824 to th client nod . 

After a new sen^ice has been added to the local 
communication directory service, the copies on the oth- 
er nodes must be updated. This updating is carried out 
in a conventbnal fashbn. For example, it is possible to 
perkxJically distribute copies on removable disks to all 
nodes, However, a more preferred method of distribut- 
ing copies of the communicatkxis directory sen^ice 
would be for the kx^al node which received the update 
to broadcast the update informatbn to alt other nodes. 
In order to accomplish this broadcast, the broadcast 
message includes a special header which causes all of 
the protocol stacks to be set to a predetermined default 
protocol. In this manner the broadcast message can be 
received at all nodes. 

Figures 11 through 13 illustrate the steps involved 
when a client applk:ation coordinates with the commu- 
ncations directory sewice to access a reiriote service. 
In partcular. Figure 11 illustrates the appropriate sec- 
tions of the client node whk;h are involved in accessing 
a remote sen^ice. As in the sen/er node, the client node 
includes a system address space 1110 which, in turn, 
contains the communicatkxis directory sewice 1112 and 
a networking service 1118. The applicatkxi program 
1100 runs in its own application address space 1104. 
The interactkxis of the apprication program 1 1 00, the di- 
rectory service 1112 and the networking sen/k;e 1118 
are described in rTK>re detail in the flow charts set forth 
in Figures 12 and 13. 

More particularly, the client service access routine 
starts in step 1200 and proceeds to step 1 202. As indi- 
cated in step 1202. the client interacts with the commu- 
nications directory service to get a reference to one of 
the servce objects stored in the communications direc- 
tory servk:e. This interactkxi is shown schematk:ally by 
arrow 1106 on Figure 11 . As previously mentioned, this 
interaction may involve a user directly if the user search- 
es over the directory tree located in the communbatons 
directory servfce 1112. Alternatively, this interactbn may 
involve an inten^ening applicatkxi program which coop- 
erates with the communications directory service to se- 
lect a service in a visual manner, such as, by dragging 
a document Icon onto a sendee kxxi. 

In any case, in accordance with step 1204. a refer- 
ence to the service object identified by the communica- 
tions directory servk;e 1 1 1 2 is retumed to the application 
program 1100 as shown schematically by arrow 1108. 
The application program, in turn, creates a client inter- 
face object 1126 in preparatbn for sending the configu- 
ration data to the network service 1118. The sen/ice ob- 
ject reference is passed by the communications direc- 
tory service 1112, via a configuration data stream 1114, 
to th client interface 1126. From the client interface 
1 1 26 the configuratkxi data is streamed over configura- 
tion data stream 1 1 1 6 to a server interf ac object 1 1 20 
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located in th networking service 1118. The service in- CI 
terface obj ect 1 1 20 is created wh n th e networking serv- 
ice 1 1 1 8 is created during system boot up and is perma- 1 . 
nently resident in the networking s rvic . 

In accordance with step 1206, application program s 
1 100 then activates the service object reference. Figure 
13 indicates, in more detail, the steps involved in acti- 
vating the service object reference. More particu tarty. - 
the activation routine starts in step 1300 and proceeds 
to step 1 302. In step 1 302, the service object reference io 
is resolved in any of the underlying physical directory 
services, rf appropriate. This resolution is performed by 
using the servk:e name located in the service object to 
search over the underlying directory services and to ob- 
tain the network address. Alternatively, if the service ref- ^5 
erence is registered in the native namespace of the 
communicatbns directory service 1112. then the servk:e 
address or the sen^ice exchange can be obtained direct- 
ly from the service object reference. 

In step 1 304, the stack definitions contained in the 20 
sen/ice object are used by the server interface 1 1 20 and 
the networking service 1 1 1 8 to set up protocol stack lay- 
ers for configuring the DRPS 1124. Next, in step 1306. 
the created stack definitions are passed to the DRPS as 
indicated by arrow 1122. These stack definitk>ns then 25 
set up DRPS 1 1 24 and configure the communfcation link 
in preparatk>n for sending request and reply data be- 
tween the applicatbn program 1100 and the remote 
service (not shown in Figure 11). 

Next, in step 1 308, the address of the session layer 30 2. 
1123 in the DRPS 1124 is returned to the server inter- 
face 1120. The activation routine then finishes in step 
1310. Returning to step 1208 of Figure 12, the server 
interface 1120 exchanges the address of the sessfon 
layer 1123 for the remote servrce exchange obtained 3S 
from the service object reference and retums the remote 
service exchange (as indicated in step 1 208), via con- 
figuratbn data stream 1116, client interface 1126 and 
data path 1102 to the application program 1100. Thus, 
when the application program communk:ates with the ^ 
remote sen^ice, it uses the remote service address 
passed through the communk:atk)ns directory service 
to the networking service. 

As set forth in step 1210, a separate data path is 
set up to send sen^ice requests from appricatbn pro- ^ 
gram 1100 to the remote service. This separate data 
path comprises data path 1 1 02, client interface 1 1 26 and 
the sessk)n layer 1 1 23 of the DRPS 1 1 24. In accordance 
with step 1212, the request information then sent out 
over physk:al communk:atton link 1130 to the rerrwte so 
sen^ice kxation. Reply information retums via DRPS 
1124, data stream 1128, client interface 1126 and data 
path 1102 to the application program 1100. The service 
request routine then finishes in step 1214. 



A multi-node computer n twork system for connect- 
ing a client nod (406, 408, 420, 422, 428) to a serv- 
er node (400. 41 2. 424. 432, 438) over a plurality of 
diff r nt communicatkxi links (316. 315, 366). said 
computer network system comprising: a plurality of 
nodes, at least one processor per node (302); a 
memory (304, 306, 313) attached to said at least 
one processor and under said processor's control; 
said computer network system characterized by: 

(a) said plurality of different communk:ation 
links differentiated by a type of service and a 
quality of service (906), said type and said qual- 
ity of service stored in saki menDory; 

(b) a plurality of protocols for transmitting data 
between said client node and sakJ server node 
across saki communication links; 

(c) sakJ memory comprising a first program log- 
(1100) and a second program bgic (1110). 

sakj first program k^icfor requesting a connec- 
tion to said server node, sakJ connectkxi de- 
pendent on said type and said quality of sen^- 
k:e; and said second program logk: for kientify- 
ing at least one of saki plurality of protocols and 
at least one of said plurality of links based on 
saki type and quality of service. 

A client node of a client-server system said client- 
sen/er system comprising a distributed computer 
network, said network comprising remote proce- 
dure call (RPC) services (1112, 804, 806). said RPC 
services accessed through a RPC protocol, said cli- 
ent node interconnected with a server node via a 
communrcatbns medium (824, 1130) to form saki 
client-server system; said client node comprising: a 
processor (302); a menx>ry (304, 306, 313) acces- 
sible by saki processor; a first program logk: (11 26) 
for processing a plurality of service packets, saki 
first program k>gic contained within an application 
program (1100), saki application program reskient 
in said memory; a network adapter for transmitting 
and receiving saki packets over saki communica- 
tions medium; and a second program logk) (1118) 
resident in said memory for transferring said pack- 
ets to and from saki adapter; 
saki client node characterized by: 

(a) a third program bgic resident in said mem- 
ory for controlling said processor, saki third pro- 
gram logk: being an cbject-oriented operating 
system; 

(b) a caller object (1106) created by said appli- 
cation program from data and f unctbns stored 
in said op rating system, said second program 
bgic responsive to said caller object, to ncap- 
sulate said packets in accordance with said 
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RPC protocol to enable said first program logic 
to call an associated service (B36) residing in a 
dispatcher object of said server node; 

(c) a dynamically-configurabi protocol stack 
(11 24) comprising a plurality of vertically-linked 
protocol layer objects, said protocol stack con- 
figured to interact with said adapter to transfer 
said packets over said communication medium 
via said adapter; and 

(d) a remote stream object (1128) for establish- 
ing synchronous data stream transactions be- 
tween said application program and said proto- 
col stack, said renrtote stream object and proto- 
col stack cooperating to complete a communi- 
catbns data path within said client node. 

3. A client node as recited in claim 2, wherein said plu- 
rality of vertically-linked protocol layer objects in- 
clude upper protocol layer objects (500, 502) that 
are unque to said applicatbn program executing in 
said client node and k>wer protocol layer objects 
(504. 506, 508, 510, 512) that are shared among 
other applicatbn programs executing in said client 
node. 

4. A client node as recited in claim 3. wherein said up- 
per protocol layers include an applk:ation layer ob- 
ject (500) for exchanging sakj packets with said ap- 
plication program. 

5. A client node as recited in claim 4, wherein sakJ up- 
per protocol layers include a presentatk>n layer ob- 
ject (502) for presenting said packets in a predeter- 
mined format to said k>wer protocol layer objects. 

6. A client node as recited in claim 5, wherein sa\6 ap- 
prtcatbn layer and presentation layer objects reside 
in a process address space (1104) of sakJ client 
node. 

7. A client node as recited in claim 6. wherein said call- 
er object and sakJ application program further re- 
side in sakJ process address space. 

8. A client node as recited in claim 7, wherein saki low- 
er protocol layer objects and said operating system 
reskJe in a system address space (1110) of sakl cli- 
ent node. 

9. A client node as recited in claim 8, wherein said re- 
mote stream object includes a fourth program logic 
to ensure a consistent format for presentation of 
said packets between said process address space 
and said system address space. 

10. A client node as recited in claim 9, wherein said re- 
mote stream object comprises one of a request/r • 
ply rTKxjel object (1128) for establishing short-t rm 



synchronous transactkxis b tween said client and 
s fv modes and a partial remote ope ratk^ns rvice 
element model object for binding said nod s over 
bng-t rm synchronous transactions. 

5 

11. A method for connecting a client node (406, 408, 
420, 422, 428) to a sewer node (400. 41 2. 424, 432, 
438) within a multi-node computer network system 
over a plurality of different communicatbn links 

10 (316, 315. 366), saki plurality of links connecting a 
plurality of nodes; each of sakl plurality of nodes 
comprising at least one processor (302); said meth- 
od comprising the steps of: 

IS (a) associating a link type of service and a link 

quality of servke with each of said plurality of 
links (802, 902, 904); 

(b) specifying a desired type of servke and a 
desired quality of service (1206); 

20 (c) identifying at least one protocol and at least 

one link based on sakl desired type of service 
and desired quality of servk:e from said linktype 
of service and link quality of servbe (1 304); and 
(d) establishing a connection between saki cli- 

25 ent node and sakJ server node using said at 

least one protocol and sakJ at least one link 
(1210). 

12. A method for connecting a client node to a server 
30 node within a client-sender system sakJ client-server 

system comprising a distributed computer network, 
saki network comprising rerrtote procedure call 
(RPC) servkes (1112. 804, 806), sakl RPC sen/ices 
accessed using a RPC protocol, said client node in- 

35 terconnected with sakJ server node via a communi- 
cations medium (824, 1 1 30) to form said client-serv- 
er system; said client node comprising: a processor 
(302); a memory (304. 306. 31 3) accessible by saki 
processor; a first program logk (1126) for process- 

40 ing a plurality of servke packets, sakl first program 
k>gic contained within an application program 
(1100), said application program reskient in saki 
memory; a network adapter for transmitting and re- 
ceiving said packets over saki communkations me- 

^ dium; and a second program bgic (1118) resident 
in said memory for transferring saki packets to and 
from said adapter; an object-oriented operating sys- 
tem (1 1 1 0) for controlling said processor, saki oper- 
ating system comprising a third program logk and 

so saki operating system resident in said memory; 
saki method comprising the steps of: 

(a) constructing a caller object (1202) by said 
first program togic from data and f unctk)ns con- 

55 tained within said operating system; 

(b) presenting said caller object to said second 
program logk (2104); 

(c) sakJ second program logic responding to 
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server nodes and a partial rernote operation service 
element rnodel object for binding said nodes ov r 
long-t rm synchronous transactions. 

Patentanspruche 



said presentation of said caller object by encap- 
sulating said pack ts in accordanc with said 
RPC protocol and enabling said first program 
logic to call an associated s rvice (836) resid- 
ing in a dispatcher object of said sen/ r node; 

(d) constructing a dynamically-configurable 
protocol stack (1 1 24) from a plurality of vertical- 
ly-linked protocol layer objects, said protocol 
stack configured to interact with saki adapter to 
transfer said packets over saki communkxation 
medium via said adapter and 

(e) constructing a remote stream object (1128) 
establishing synchronous data stream transac- 
tbns between sakj application program and 
said protocol stack. sakJ remote stream object 
and sakJ protocol stack cooperating to com- 
plete a communications data path within said 
client node. 

13. A method as recited in claim 1 2. wherein construct- 
ing saki dynamically-configurable protocol stack 
comprises: 

(d1) assembling upper protocol layer objects 
that are unique to said application program ex- 
ecuting in said client node; and 
(d2) assembling lower protocol layer objects 
that are shared annong other applicatbn pro- 
grams executing in said client node. 

14. A method as recited in claim 13, wherein assem- 
bling said upper protocol layer objects further com- 
prises including an applk^atbn layer object for ex- 
changing said packets with said applk:ation pro- 
gram. 

15. A method as recited in claim 14, wherein assem- 
bling said upper protocol layer objects further com- 
prises including a presentation layer object for pre- 
senting said packets in a predetermined format to 
said lower protocol layer objects. 

16. A method as recited in claim 1 5 wherein sakl appli- 
catkxi layer object, said presentatbn layer objects 
said caller object and said application program re- 
side in saki process address space of sakJ client 
node, and said lower protocol layer objects and said 
operating system reside in a system address space 
of said client node; 

said method further comprising sakJ remote stream 
object ensuring a consistent format for said presen- 
tation of said packets between said process ad- 
dress space and said system address space. 

17. A method as recited in claim 16, wherein sakJ re- 
mote stream object comprises on of a request/re- 
ply model object for establishing short-term syn- 
chronous transactions between said client and 



1. Ein Vielfachknoten-Computer-Netzwerksystem 
zum Verbinden eines Client-Netzknotens (406, 

10 408. 420, 422. 428) mrt einem Server-Netzknoten 
(400, 41 2, 424. 432. 438) uber eine Vielzahl von un- 
terschiedlichen Kommunikatbnsverblndungen 
(316, 315, 366), besagtes Computer-Netzwerksy- 
stem enthalt eine Vielzahl von Netzknoten, wenig- 

15 stens ein en Prozessor pro Netzknoten (302), einen 
Speicher (304, 306. 313), der an besagten wenig- 
stens einen Prozessor angeschlossen ist und von 
diesem gesteuert wird, besagtes Computer-Netz- 
werksystem ist gekennzeichnet durch: 

20 

(a) besagte Vielzahl von unterschiedlichen 
Kommunikationsverbindungen ist unterschie- 
den nach einem Servicetyp und einer Servce- 
qualitat (906). besagter Typ und besagte Qua- 
25 litat sind in besagtem Speicher gespeichert; 



(b) eine Vielzahl von Protokollen zur Ubertra- 
gung von Daten zwischen besagtem Client- 
Netzknoten und dem besagten Server-Netz- 

30 knoten uber besagte Kommunikationsverbin- 

dungen; 

(c) besagter Speicher enthalt eine erste Pro- 
grammlogik (1100) und eine zweite Programm- 

35 k>gik (1110), besagte erste Programmbgik 

dient zur Anforderung einer Verbindung zu be- 
sagtem Server-Netzknoten. besagte Verbin- 
dung ist abhangig von besagtem Typ und be- 
sagter Quai'rtat des Sen/k;es; und besagte 

40 zweite Programmk)gik dient zur identifizierung 

von wenigstens einem der besagten Vielzahl 
von Protokollen und wenigstens etner der be- 
sagten Vielzahl von Verbindungen auf der Ba- 
sis von besagtem Typ und besagter Qualitat 

45 des Services. 

2. Ein Client-Netzknoten eines Client-Sen/er-Sy- 
stems, das ein verteiltes Computer-Netzwerk ent- 
halt, besagtes Netzwerk umfaBt Prozedur-Femauf- 

50 njf(RPC)-Dienste (1112. 804. 806), auf besagte 
RPC Dienste wird durch ein RPC Protokoll zuge- 
griffen, besagter Client-Netzknoten ist mit einem 
Server-Netzknoten uber ein Kommunikatbnsmedi- 
um (824, 1130) verbunden zur Bildung des besag- 

55 ten Client-Server-Systems; besagter Client-Netz- 
knoten nthatt einen Prozessor (302); einen Spei- 
cher (304, 306, 313), auf den durch besagten Pro- 
zessor zugreifbar ist; eine erste Programmbgik 
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(1126) zur Verarbeitung einer Vielzahl von Service- 
pak ten, besagt erst Programmlogik ist in inem 
Anwendungsprogramm (1100) enthatten, das in be- 
sagtem Spebher resid ntist; in n Netzwerkadap- 
ter zum Aussenden und Empfangen b sagt r Pa- s 
kete uber besagtes Komnnunlkatk>nsmedium; und 
einezweite Programmk>gik (1118), die in besagtenn 
Spercher resident ist zum Ubertragen besagter Pa- 
kete zu und von besagtem Adapter; besagter Cli- 
ent-Netzknoten Ist gekennzeichnet durch: io 

(a) eine dritte Programnnlogik, die in besagtem 
Speicher resident ist zur Steuerung des besag- 
ten Prozessors, besagte dritte Programmlogik 

ist ein objektorientiertes Betriebssystem; is 

(b) ein Aufrufobjekt (1106), das durch das be- 
sagte Anwendungsprogramm aus in besagtem 
Betriebssystem gespeicherten Daten und 
Funktk>nen erzeugt wird, besagte zweite Pro- 20 
grammbgik spricht auf besagtes Aufrufobjekt 

an zur Einkapselung besagter Pakete in Uber- 
einstimmung mit besagtem RPC Protokoll, um 
die besagte erste Programmlogik in die Lage 
zu versetzen. einen verbundenen Service 2S 
(836) autzurufen, der in einem Dispatcher-Ob- 
jekt des besagten Sen/er-Netzknotens enthal- 
ten ist; 

(c) einen dynamisch konfigurierbaren Proto- 30 
kollstapel (1124), der eine Vielzahl von vertikal 
verbundenen ProtokollschchtObjekten ent- 
halt, besagter Protokollstapel ist konfiguriert, 

mit besagtem Adapter zusammenzuwirken 
zum Ubertragen besagter Pakete uber besag- 3S 
tes Kommunikatkxismedium durch besagten 
Adapter; und 

(d) ein Fem-Stromungs-Objekt (1128) zum 
Herstellen synch roner Datenstrom-Transaklk>- 40 
nen zwischen besagtem Anwendungspro- 
grannm und besagtem Protokollstapel, besag- 
tes Fem-Stromungs-Objekt und besagter Pro- 
tokollstapel kooperieren zur Ven^ollstandigung 
eines Kommunikatonsdatenpfades innerhalb 45 
des besagten Client-Netzknotens, 

Ein Client-Netzknoten nach Anspruch 2, worin be- 
sagte Vielzahl von vertikal verbundenen Protokoll- 
schicht-Objekten obere Protokollschrcht-Objekte so 
(500, 502) enthatten, die allein dem besagten An- 
wendungsprogramm zugeordnet sind. das in be- 
sagtem Client-Netzknoten ausgefuhrt wird, und un- 
tere Protokollschicht-Objekte (504, 506, 508, 510, 
51 2) enthalten, in die sch andere Anwendungspro- ss 
gramme teilen, di in besagtem Client-Netzknoten 
ausgefuhrt werden. 



4. Ein Client-Netzknoten nach Anspruch 3, worin be- 
sagte obere Protokollschk:ht n ein Anwendungs- 
schicht-Objekt (500) enthalten zum Austausch be- 
sagter Pakete mit dem b sagten Anwendungspro- 
gramm. 

5. Ein Client-Netzknoten nach Anspruch 4, worin be- 
sagte obere Protokollschichten ein Prasentatk>ns- 
schicht-Objekt (502) enthalten zur Prasentatkxi be- 
sagter Pakete den besagten unteren Protokoll- 
schicht-Objekten in einem vorgegebenen Format. 

6. Ein Client-Netzknoten nach Anspruch 5, worin sich 
besagtes Anwendungsschicht-Objekt und besag- 
tes Prasentatkxisschicht-Objekt in einem 
Proze8adressraum (1104) des besagten Client- 
Netzknotens gespeichert sind. 

7. Ein Client-Netzknoten nach Anspruch 6, worin be- 
sagtes Aufrufobjekt und besagtes Anwendungspro- 
gramm ebenfalls in besagtem Proze8adressraum 
enthalten sind. 

8. Ein Client-Netzknoten nach Anspruch 7, worin be- 
sagte untere ProtokollschichtObjekte und besag- 
tes Betriebssystem in einem Systemadressraum 
des besagten Client-Netzknotens enthalten sind. 

9. Ein Client-Netzknoten nach Anspruch 8, worin be- 
sagtes Fem-Stromungs-Objekt eine vierte Pro- 
grammlogik enthalt zur Sicherung eines konsisten- 
ten Formats zur Darsteltung von besagten Paketen 
zwischen besagtem Proze8adressraum und be- 
sagtem Systemadressraum. 

10. Ein Client-Netzknoten nach Anspruch 9, worin be- 
sagtes Fem-Stromungs-Objekt ein Anforderung/ 
Antwort-Modell-Objekt (1128) enthalt zur Ausfuh- 
rung von kurzzeitigen synchronen Transaktbnen 
zwischen besagten Client- und Sen^er-Netzknoten 
und ein Teil-Fem-Operatbns-Service-Element-Mo- 
del-Objekt zum Verbinden der besagten Netzkno- 
ten f Or synchrone Langzert-Transaktionen. 

11. Ein Verfahren zur Kopplung eines Client-Netzkno- 
tens (406, 408, 420, 422, 428) mit einem Server- 
Netzknoten (400. 41 2, 424, 432, 438) in einem Viel- 
fachknoten-Computer-Netzwerksystem uber eine 
Vielzahl von unterschiedlichen Kommunikatkxis- 
verbindungen (316, 315, 366), besagte Verbindun- 
gen verbinden eine Vielzahl von Netzknoten; jeder 
der besagten Vielzahl von Netzknoten enthalt we- 
nigstens einen Prozessor (302); besagtes Verfah- 
ren umfa8t die Schritte: 

(a) Verknupfen eines Verbindung-Servic typs 
und einer Verbindung-Sen/icequalitat mit jeder 
. der besagten Vielzahl von Verbindung n (802, 
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- 902,904); 

(b) Angeben eines gewOnschten Servicetyps 
und in rg wunschtenS rvicequalitat (1206); 

(c) Identifizieren von wenigstens einem Proto- 
koll und von wenigstens einer Verknupf ung. die 
auf dem besagten gewOnschten Sen^icetyp 
und der besagten gewOnschten Servicequalitat 
von besagtem Verbindung-Servicetyp und be- 
sagter Verbindung-Sen^icequalitat (1304) be- 
ruht; und 

(d) Herstellen einer Kopplung zwischen besag- 
ten Client-Netzknoten und besagten Server- 
Netzknoten unter Verwendung des besagten 
wenigstens einem Protokolls und der besagten 
wenigstens einen Verbindung (1210). 

12. Ein Verfahren zur Kopplung eines Client-Netzkno- 
ten mit einem Sen/er-Netzknoten in einem Client- 
Server-Systems, das ein verteiltes Computer-Netz- 
werk enthatt, besagtes Netzwerk umfaftt Prozedu- 
ren-Femautruf (RPC) Dienste (1112. 804, 806), auf 
besagte RPC Dienste wird durch ein RPC Protokoll 
zugegriffen, besagter Client-Netzknoten ist mit ei- 
nem Server-Netzknoten Ober ein Kommunikations- 
medium (824, 11 30) verbunden zur BikJung des be- 
sagten Client-Server-Systenns; besagter Client- 
Netzknoten enthalt einen Prozessor (302); einen 
Spewher (304, 306, 313), der durch besagten Pro- 
zessor zugreifbar ist; eine erste Programmlogik 
(1126) zur Verarbeitung einer Vielzahl von Service- 
paketen, besagte erste Programmlogik ist in einem 
Anwendungsprogramm (1 1 00) enthalten, das in be- 
sagtem Spek:her resklent ist; einen Netzwerkadap- 
ter zum Aussenden und Empfangen besagter Pa- 
kete Ober besagtes Kommunikatkxismedium; und 
eine zweite Programmbgik (1118), die in besagtem 
Speicher reskient ist zum Ubertragen besagter Pa- 
kete zu und von besagtem Adapter; ein objektori- 
entiertes Betriebssystem, das eine drrtte Pro- 
grammk>gik umtalM und das in besagtem Speicher 
enthalten ist; 

besagtes Verfahren umfaOt die Schritte: 

(a) Erzeugen eines Aufrufobjekts (1202) durch 
besagte erste Programmlogik aus in besagtem 
Betriebssystem enthaltenen Daten und Funk- 
tk>nen; 

(b) Prasentieren des besagten Aufrufobjekts 
der besagten zweiten Programmbgik (21 04); 

(c) Antworten durch besagte zweite Programm- 
logik auf das besagte Prasentieren des besag- 
ten Aufrufobjekts durch Einkapsetung besagt r 
Paket in Ubereinstimmung mit besagtem RPC 



Protokoll und Aktivieren besagter rsten Pro- 
grammlogik zum Aufruf ines verbundenen 
Services (636), der in einem Dispatch r-Objekt 
des besagten Sen^ r-Netzknotens nthatten 

5 1st; 

(d) Erzeugen eines dynamisch konfigurierba- 
ren Protokollstapels (1124) aus einer Vielzahl 
von vertikal verbundenen Protokollschcht-Ob- 

10 jekten enthalt, besagter Protokotlstapel ist kon- 

figuriert, mit besagtem Adapter zusammenzu- 
wirken zum Ubertragen besagter Pakete Ober 
besagtes Kommunikatkxismedium durch be- 
sagten Adapter; und 

IS 

(e) Erzeugen eines Fem-Stromungs-Objekts 
(11 28) zum Herstellen synchroner Datenstrom- 
Transaktkxien zwischen besagtem Anwen- 
dungsprogramm und besagtem Protokollsta- 

20 pel, besagtes Fem-Stromungs-Objekl und be- 

sagter Protokollstapel kooperieren zur Ven/oll- 
standlgung eines Kommunikationsdatenpfa- 
des innerhaib des besagten Client-Netzkno- 
tens. 

2S 

13. Ein Verfahren nach Anspruch 12, worin die Erzeu- 
gung eines dynamisch konfigurierbaren Protokoll- 
stapels umfaOt: 

30 (dl) Assemblieren von oberen Protokoll- 

schicht-Objekten, die allein dem besagten An- 
wendungsprogramm zugeordnet sind, das in 
besagtem Client-Netzknoten ausgefuhrt wird; 
und 

35 

(d2) Assemblieren von unteren Protokoll- 
schicht-Objekten, in die sich andere Anwen- 
dungsprogramme teilen, die in besagtem Cli- 
ent-Netzknoten ausgefuhrt werden. 

40 

14. Ein Verfahren nach Anspruch 1 3, worin das Assem- 
blieren besagter oberer Protokoilschicht-Objekte 
die Einbeziehung eines Anwendungsschk;ht-Ob- 
jekts umtaOt zum Austausch besagter Pakete mit 

45 besagtem Anwendungsprogramm. 

15. Ein Verfahren nach Anspruch 1 4, worin das Assem- 
blieren besagter oberer Protokollschichten die Ein- 
beziehung eines Prasentationsschbht-Objekts um- 

50 faBt zur Presentation besagter Pakete den besag- 
ten unteren Protokollschrcht-Objekten in einem vor- 
gegebenen Format. 

16. Ein Verfahren nach Anspruch 15, worin sich besag- 
55 tes Anwendungsschkiht-Objekt, besagte Prasenta- 

tkxisschbht-Obj kte, b sagtes Aufrufobjekt und 
besagtes Anwendungsprogramm in besagtem Pro- 
zeOadressraum des besagten Client-Netzknotens 
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enthatten sind, und besagte untere Protokoll- 
schicht-Objekte und besagtes Beth bssyst mtnei- 
nem Systemaddressraum d s besagten Client- 
Netzknotens enthalten sind; 

besagtes Fem-Stromungs-Objekt st Itt in konsi- 5 
stentes Format sich r zur Prasentation von besag- 
ten Paketen zwischen besagtem ProzeSadress- 
raum und besagtem Systemadressraum. 

17. Ein Verfahren nach Anspruch 16, worin besagtes io 
Fem-Stromungs-Objekt ein Antorderung/Antwort- 
Modelt-Objekt (1128) enthalt zur Ausfuhrung von 
kurzzeitigen synchronen Transaktionen zwischen 
besagten Client- und Server-Netzknoten und ein 
Teil-Fem-Operatk>ns-Service-Element-Model-Ob- is 
jekt zum Verbinden der besagten Netzknoten fur 
synchrone Langzeit-Transaktkxien. 



Revendlcattons 20 

1. Syst6me de r6seau d'ordinateurs multl-noeud pour 
connecter un noeud client (406, 408, 420, 422, 428) 
d un noeud serveur (400, 412, 424, 432, 438) par 
une pturalite de liaisons de communk:ation diff^ren- 2S 
tes (316, 315, 366), ledit systdme de rdseau d'ordi- 
nateurs comprenant une plural ite de noeuds, au 
moins un processeur par noeud (302), une m6moire 
(304, 306, 31 3) connect ee audit processeur et sous 

le contrdle du processeur, 30 

ledit systdme de rdseau d'ordinateurs 6tant 
caract6ris6 par : 

a) ladite plurality de liaisons de communication 
differentes est diff6renci6e par un type de ser- ^ 
vice et une quality de sen^tce (906), tesdits type 

et quality de service 6tant emmagasin^ dans 
ladite m^moire, 

b) une plurality de protocoles pour transmettre 
des donn^es entre un noeud client et ledit 40 
noeud serveur au moyen desdites liaisons de 
communication, 

c) ladite m6moire comprend une premiere bgi- 
que programme (1 1 00) et une seconde bgque 
programme (1 110), ladite premiere logique pro- 4S 
gramme demandant une connexkxi audit 
noeud sen/eur. ladite connexion dependant du- 

dit type et de ladite quality de service, et ladite 
seconde bgique programme identifiant au 
moins un parmi ladite plurality de protocoles et so 
au moins une parmi ladite plurality de liaisons 
bas6s sur ledit type et ladite quality de service. 

2. Noeud client tfun syst6me sen/eur de clients, ledit 
syst6me comprenant un r6seau d'ordinateurs dis- ss 
tribu6, ledit r6seau comprenant des services d'ap- 

pel (RPC) de procedure 6toign6s (1112, 804, 806) 
dont I'acc^ s fait par un protocote RPC, ledit 



noeud client 6tant interconnects avec un noeud ser- 
V ur via un support d communication (824. 1130) 
pour former ledit system e serveur de clients, ledit 
noeud client compr nant : un processeur (302), un 
memoir (304, 306, 313) accessibi par ledit pro- 
cesseur, une premier logiqu de programme 
(1126) pour traiter une plurality de paquets de ser- 
vk:e, iadite bgique de programme 6tant contenue 
dans un programme d'application (1100), ledrt pro- 
gramme d'applicatbn r6skiant en mSmoire, un 
adaptateur de rSseau pour transmettre et recevoir 
lesdits paquets sur ledit support de communication, 
et une seconde logique de programme (1118) r6si- 
dant dans ladite mSmoire pour transferer lesdits pa- 
quets au et ^ partir dudit adaptateur, ledit noeud 
client dtant caract6ris6 par : 

a) une troisi^me logk^ue de programme r6si- 
dant dans ladite mSmoire pour contrdler ledit 
processeur, tadite troisi^me logique de pro- 
gramme Slant un systSme d'expk>itation orien- 
ts objet. 

b) un objet d'appel (1106) crSS par ledit pro- 
gramme d'application d partir des donnSes et 
des fonctions emmagasinSes dans ledit systS- 
me d'exploitation, ladite second k^gique de pro- 
gramme Stant sensible audit objet d'appel pour 
encapsuler lesdits paquets conformSment 
audit protocole RPC pour permettre ^ ladite 
premiSre logique de programme d'appeler un 
service associS (836) rSsidant dans un objet de 
distribution dudit noeud serveur, 

c) une pile de protocoles pouvant etre configu- 
rSe de fagon dynamique (1124) comprenant 
une plurality d'objets de couches de protocole 
\\6s vertcalement, ladite pile Stant configurSe 
pour interagir avec ledit adaptateur pour trans- 
fSrer lesdits paquets sur ledit support de com- 
munication via ledit adaptateur, et 

d) un objet de flot SloignS (1128) pour Stablir 
des transactions par sequences de donnSes 
synchronisSes entre ledit programme d'appli- 
cation et ladite pile de protocoles, ledit objet de 
fbt et ladite pile de protocoles coopSrant pour 
completer un chemin de donnSes de commu- 
ncatkxi h I'intSrieur dudit noeud client 

3. Noeud client tel que dSftni dans la revendicatk»i 2, 
dans lequel tadite pluratitS d'objets de couches de 
protocole liSs vertk^alement comprend des objets 
de couches de protocole supSrieures (500, 502) qui 
sont unkques pour ledit programme d'application 
s'exScutant dans ledit noeud client et des objets de 
couches de protocole infSrieures (504, 506, 508, 
510. 512) qui sont partagSs par d'autres program- 
mes d'applicatkxi s'exScutant dans ledit noeud 
client. 
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4. Noeud client tel que d6fini dans la revendication 3, 
dans lequel les couches de protocol sup6rieures 
comprennent un objet de couche d'appltcation 
(500) pour ^changer lesdrts paquets avec ledrt pro- 
gramme d'appltcation. 

5. Noeud client tel que d^fini dans la revendication 4, 
dans lequel les couches de protocole supSrieures 
comprennent un objet de couche de presentation 
(502) pour presenter lesdits paquets dans un format 
pr6d6termin6 auxdits objets de couches de proto- 
cole infdrieures. 

6. Noeud client tel que d6fjni dans la revendication 5, 
dans lequel lesdits objets de couche d'appltcation 
et de couche de presentation resident dans un es- 
pace adresse de procddds (1104) dudrt noeud 
client. 

7. Noeud client tel que d^fini dans la revendication 6, 
dans lequel ledit objet d'appel et ledit programme 
d'application resident en outre dans ledit espace 
adresse de procddd. 

8. Noeud client tel que d6fini dans la revendication 7, 
dans tequet lesdrts objets de couches de protocole 
inierleures et ledit systdme d'exploitation resident 
dans un espace adresse de systdme (1110) dudit 
noeud client. 

9. Noeud client tel que d6fini dans la revendication B, 
dans lequel ledit objet de flot eloign^ comprend une 
quatri^me logique de programme pour assurer un 
format conststant pour la presentation desdits pa- 
quets entre ledit espace adresse de proc^de et ledit 
espace adresse de systeme. 

10. Noeud client tel que defini dans la revend'tcation 9, 
dans lequel ledit objet de flot etoigne comprend un 
des objets modules de requdte/reponse (1 1 28) pour 
etablir des transactions synchrones court terme en- 
tre lesdits noeuds client et serveur et un objet mo- 
dule d'6l6ment de service d'ope ration eioignde par- 
tielle pour lier lesdits noeuds sur des transactions 
synchrones long terme. 

11 . Methode pour connecter un rtoeud client (406, 408, 
420, 422, 428) ^ un noeud serveur (400, 412, 424, 
432, 438) dans un systeme de r^seau d'ordinateurs 
multi-noeud, ) par une plurality de liaisons de com- 
munication differentes (316, 315, 366), ladite plura- 
lity de communications connectant une plurality de 
noeuds, chacun de ladite plurality de noeuds copd- 
prenant au moins un processeur (302), ladite me- 
thode comprenant les etapes de : 

a) associer un type de sennce de liaison et une 
qualitedesen^ic de liaison ^chacuned ladite 



plurality de liaisons (802, 902, 904), 

b) specifier un typ de s rvloe desire et un 
qualite de service desiree, 

c) identifi r au rTK)ins un protocole t au moins 
un liaison bas6e sur ledit type d senate de- 
sire et ladite qualite d service desiree k partir 
dudit type de service de liaison et de ladite qua- 
lite de sen^ice de liaison, (1304), et 

d) etablir une connexion entre ledit noeud client 
et ledit noeud sen/eur en utilisant ledit protoco- 
le et ladite liaison (1210). 

12. Methode pour connecter un noeud client k un 
noeud serveur dans un systeme sen^eurde clients, 
ledit systeme serveur de clients comprenant un r6- 
seau d'ordinateurs distribue, ledrt reseau compre- 
nant des services d'appel (RPC) de procedure eioi- 
gnes (1112, 804, 806) lesdits services RPC etant 
accedes en utilisant un protocole RPC, ledit noeud 
client etant interconnecte avec un noeud serveur 
via un support de communication (824. 1130) pour 
former ledrt systeme sen/eur de clients, ledit noeud 
client comprenant: un processeur (302), une me- 
moire (304, 306. 313) accessible par ledit proces- 
seur, une premiere logique de programme (1126) 
pour traiter une plurallte de paquets de service, la- 
dite logique de programme etant contenue dans un 
programme d'appltcation (1100), ledit programme 
d'application residant en memoire, un adaptateur 
de reseau pour transmettre et recevoir lesdits pa- 
quets sur ledit support de communication, et une 
seconde logique de programme (1118) residant 
dans ladite memoire pour transferer lesdits paquets 
au et k partir dudit adaptateur, un systeme d'exploi- 
tation oriente objet (1110) pour controler [edit pro- 
cesseur, ledit systdme d'exploitation comprenant 
une troisieme logique de programme et ledit syste- 
me d'exploitation residant dans ladite memoire ; 
ladite methode comprenant les etapes de :: 

a) construire un objet d'appel (1202) par ladite 
premiere logique de programme k partir des 
donnees et des fonctions emmagasinees dans 
ledrt systeme d'exploitation, 

b) presenter ledit objet d'appel k la seconde k>- 
g'tque de programme (2104), 

c) ladite second logique de programme repon- 
dant k la presentation dudit objet d'appel en en- 
capsutant lesdits paquets contormement audit 
protocole RPC pour permettre k ladite premiere 
logique de programme d'appeler un service as- 
socie (836) residant dans un objet de distribu- 
tion dudit noeud serveur, 

d) construire une pile de protocoles pouvant 
etre configuree de fagon dynamique (1124) k 
partir d'un pluralite d'objets d couches de 
protocole lies verticalement, tadite pile de pro- 
tocoles etant configuree pour interagir avec I - 
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dit adaptateur pour transferer tesdits paquets synchrones long term . 

sur ledrt support de communication via ledit 
adaptateur, et 

e) construire un obj t de flot 6loign6 (11 28) 6ta- 
blissant des transactions par s^uenc s de s 
donn6 s synch ronis6es entre ledit programme 
d'application et ladite pile de protocoles. ledit 
objet de flot et ladite pile de protocoles coop6- 
rant pour completer un chemin de donn^es de 
communication ^ I'intdrieur dudit noeud client. io 



13. M6thode telle que ddfinie dans la revendication 12, 
dans laquelle ladite pile de protocoles pouvant §tre 
configur6e de fagon dynamique comprend : 

75 

d1) I'assemblage d'objets de couches de pro- 
tocole superieures qui sont uniques pour ledit 
programme d'application s'exdcutant dans ledit 
noeud client et 

d2) Tassemblage d'objets de couches de pro- 20 
tocole inferieures qui sont partag6s par 
d'autres programmes d'application s'exteutant 
dans ledit noeud client. 



14. M^thode telle que d6finie dans la revendication 1 3, 2S 
dans laquelle I'assemblage desdits objets de cou- 
ches de protocole superieures comprend inclusion 
d'un objet de couche d'application pour ^changer 
lesdits paquets avec ledit programme d'application. 

30 

15. Methode telle que d6finie dans la revendication 14, 
dans laquelle I'assemblage desdits objets de cou- 
ches de protocole sup6rieures comprend I'incluslon 
d'un objet de couche de presentation pour presen- 
ter lesdits paquets dans un format predetermine 35 
auxdits objets de couches de protocole inferieures. 



16. Methode telle que detinie dans la revendication 15, 
dans laquelle ledit objet de couche d'application , 
lesdits objets de couche de presentation et ledit pro- ^ 
gramme d'application resident dans un espace 
adresse de procedes dudit noeud client, et lesdits 
objets de couches de protocole inferieures et ledit 
systeme d'exploitation resident dans un espace 
adresse de systeme dudit noeud client, ^ 

ladite methode comprenant en outre ledit ob- 
jet de flot eioigne assurant un format consistant 
pour la presentation desdits paquets entre ledit es- 
pace adresse de procede et ledit espace adresse 
de system e. so 

17. Methode telle que definie dans la revendication 16. 
dans laquelle ledit objet de flot eioigne comprend 
un des objets modules de requdte/reponse pour 
etablir des transactions synchrones court terme en- ^ 
tr lesdits noeuds client et serveur et un objet rTK> 
deie d'eiement de sen^ice d'operation eioignee par- 
tielle pour lier lesdits noeuds sur des transactions 
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